Pass your certification exam. Faster. Guaranteed.

Certificate and Registration Authorities Transcription

Welcome to our Public Key Infrastructure module. In this module, we will discuss certificate authorities and registration authorities. With public key infrastructure, it is very important to make sure we have a system in place to issue, store, and revoke digital certificates. Certificate authorities are responsible for creating and issuing digital certificates.

A certificate authority could be a trusted third party, such as Verisign or Symantec, or you could have an internal certificate authority in your organization which issues certificates. Before a certificate is issued, the user must provide some identification information to a certificate authority. The certificate authority then verifies the information prior to issuing the certificate.

In a decentralized environment, the user generates their public and private key pair and sends the public key only to the certificate authority. In a centralized environment, the certificate authority would issue the public and private keys to the user. Once the public and private key pair has been generated, the certificate authority creates the certificate.

The certificate authority will insert important information as well as the public key and then they will digitally sign the certificate to make it tamper proof. These certificates operate under the X.509 standard. We also have registration authorities which are licensed certificate distributors or middlemen. They can handle some of the tasks of the certificate authority such as receiving requests, verifying users' identities and revoking credentials, but the certificate authority is the only one who is permitted to create certificates.

The registration authority does not create certificates and you may see a question on the CISSP exam asking about who can issue a digital certificate and only the certificate authority is permitted to do that. The certificate authority can be either a public or outside internet certificate authority that will sell additional certificates.

Or it can be an inside or create your own certificate authority. Public certificate authorities, like VeriSign, are able to create certificates and sell them and they can be used on the internet. You are required to pay a fee for these certificates. Certificates generated by a private certificate authority, or one in your own organization, do not cost money because you are generating them within your organization, using your administrators to create certificates for your systems and your users.

However, these credentials are not valid on the internet because you've created them internally and they were not created by a publicly trusted certificate authority. And we can have hierarchical certificate authority and registration authority trust models in a private certificate authority environment. With a public key infrastructure, we have our root certificate authority who is at the top of the hierarchy. The root certificate authority is the only entity that signs their own certificate. The subordinate certificate authorities have certificates that are signed by the root certificate authority. The root certificate always trusts its subordinate certificate authorities and the subordinate certificate authorities always trust the root certificate authority. We do have something called bridge trust and that would be in this particular example, where the two subordinate certificate authorities trust each other.

We can have bridge trust but it's not required. In this example, we do not see any trust relationship between the two subordinate certificate authorities. Here we will take a look at how different certificate authorities will communicate with each other. Certificate authorities use a hierarchy where authority is delegated to subsidiary certificate authorities and all of the certificate authorities towards the root are trusted as we move up this chain of trust.

The root certificate authority is always at the top of our hierarchy and it initiates all of the trust paths between the other certificate authorities. All of the certificate holders and any parties that rely on certificates have certificates that are validated by the self signed certificate of the root certificate authority.

Only the root certificate authority is permitted to sign their own certificate. And these root certificate authorities could be Verisign, Entrust or if you're using a private certificate authority, one that you create within your enterprise. Subordinate certificate authorities do not begin the trust path. The trust path is always initiated by the root certificate authority and subordinate certificate authorities can have additional subordinate certificate authorities of their own to which they issue certificates.

You can also have root to root trust, where two root certificate authorities trust each other, and this is usually done for the purposes of single sign on or SSO. As we can see in the graphic at the bottom right, it is risky to have certificate authorities trust each other or cross-certify each other.

It's important to have a root certificate authority in place to manage this process. A certificate repository is a database of digital certificates and public keys that is created by the certificate authority. This is typically available to users through their email system, such as with the exchange global address list, or with the PGP key store or from a web browser interface.

This allows users to look up other users public keys so that they can use that recipient's public key to encrypt data before sending it to them. Microsoft exchange offers the global address list, which is a directory that has an entry for every group, user and contact within an organization.

And the digital certificate can be attached to this contact information. This makes it very easy for users. And most users do not even know that this digital signature process is occurring in the background when they are sending and receiving emails between their trusted contacts. This concludes our public key infrastructure module, thank you for watching.